Binding graphic elements to controller data

ABSTRACT

Graphic element definitions are bound to industrial automation data types in an industrial control system. Moreover, a system provides automatic data searching and filtering of an item based on user interactions with either the graphic element definition or a controller data type. Further, a graphic element definition is associated with a data source type information, to simplify configuration of an instance of that graphic element and populate suitable data source fields based on instances of the associated data source type. In addition, a system to automatically generate the graphic element based on data from a logic controller is provided. Moreover, the graphic element can be updated to reflect a change in the data, without a manual refresh.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and claims priority to U.S.patent application Ser. No. 13/171,114, filed Jun. 28, 2011 and entitled“BINDING GRAPHIC ELEMENTS TO CONTROLLER DATA,” which is related toco-pending U.S. patent application Ser. No. 12/869,524, filed on Aug.26, 2010, entitled “AUTOMATED OPERATOR INTERFACE GENERATION IN A CONTROLSYSTEM.” The entireties of each of the above noted applications areincorporated herein by reference.

TECHNICAL FIELD

The subject disclosure relates to automation control, and morespecifically, to a system and method for binding graphic elements tocontroller data.

BACKGROUND

Industrial control systems regulate operation of equipment in anindustrial environment, where operation of the equipment includesprocess(es) typically directed to accomplishment of a complex task or astreamlined, automated task, such as large scale manufacturing.Regulation of operation of the equipment and related process(es)typically exploit and produce substantive amounts of control data, whichinclude configuration data such as controller code, human-machineinterface (HMI) data, process recipe(s) and report definitions, or thelike. In addition, operation of industrial control systems also producesboth real-time and historical data about the status of regulatedequipment and related process(es), the data including alarms, processvalues, and audit/error logs. To operate industrial control systems,various HMIs in the industrial environment render control data(real-time (or last known) and historical data) through operatorinterfaces which convey process overviews or equipment detail. Multipleoperator interfaces are created to provide rich information related tothe various control processes implemented in the industrial controlsystem so that the operator can switch between them to monitor variousaspects of the equipment and related process(es) under control.

Various factors contribute to the time and human resources necessary toconfigure operator interface(s) employed to render control data in anindustrial environment; such factors include complexity of the equipmentand related process(es) that are regulated through one or morecontrollers, amount of control data collected as part of controlling theequipment and the related process(es), and security protocols andassociated data necessary to ensure operational integrity of theequipment. Yet, in conventional industrial control systems, developmentof an operator interface to consume control data through a dedicatedhuman-machine interface (HMI) is a highly manual process that generallyoccurs after control design or equipment configuration and contributessignificantly to the development cost. Specifically, most traditionalHMI systems do not support structured data types, and those that dosupport structured data, provide only one-way interactions.

SUMMARY

The following presents a simplified summary in order to provide a basicunderstanding of some aspects of the subject disclosure. This summary isnot an extensive overview, and it is not intended to identifykey/critical elements of the subject disclosure or to delineate anyscope. The sole purpose of this summary is to present some concepts in asimplified form as a prelude to the more detailed description that ispresented later.

One or more embodiments in the subject disclosure provide a system andmethod for providing a bi-directional binding between graphic elementsand industrial automation data types. For example, a definition of agraphic element can be bound/linked/mapped to a controller data type.Moreover, type mappings, such as, but not limited to, strongly-typed,loosely-typed, and/or un-typed mappings can be utilized to bind aproperty within the graphic element definition to the controller datatype. Typically, the system disclosed herein can provide support forbi-directional workflows with graphic elements and data types,including, but not limited to, structured data types.

Further, another embodiment of the subject specification includesmethods and systems for associating/linking/binding a definition of agraphic element with a data source definition, for example, a userdefined type (UDT) or an add on instruction (AOI). Moreover, when aninstance of the graphic element is created, for example in an HMIconfiguration environment, the instance can be configured based onpopulation of data source fields by employing instances of the datasource type. Typically, a user input can be received to select suitabledata sources from a previously configured program file.

Yet another embodiment of the subject disclosure provides a system andmethod that automatically generates graphic elements based on controllercontent. Moreover, a new, e.g., previously un-programmed, human machineinterface (HMI) can be connected to a logic controller and based on thedata on the logic controller, a set of screens can be automaticallycreated in the HMI, with or without (or with minimal) user interaction.In addition, the HMI application can be refined, customized, and/ormodified as the controller program is modified (e.g., tag renamed, newcontrol programs, etc.). Moreover, HMI content can be dynamicallydisplayed and modified on a terminal as the controller program is beingrefined, customized, and/or modified.

To the accomplishment of the foregoing and related ends, certainillustrative aspects of the disclosed innovation are described herein inconnection with the following description and the annexed drawings.These aspects are indicative, however, of but a few of the various waysin which the principles disclosed herein can be employed and is intendedto include all such aspects and their equivalents. Other advantages andnovel features will become apparent from the following detaileddescription when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram that illustrates a bi-directional mechanism forbinding human machine interface (HMI) graphic element definitions tocontroller data types.

FIG. 2 illustrates an example system that enables and exploits mappinggraphic element definitions to controller data types, in an industrialautomation system.

FIG. 3 illustrates an example system overview of the resources in aproject and its associated product and project libraries in anindustrial automation environment.

FIGS. 4A-E illustrate example screenshots relating to a visual layout ofan example graphic element definition in accordance with one or moreaspects disclosed herein.

FIGS. 5A-C illustrate example screenshots that depict configuration ofproperties of a graphic element in accordance with aspects describedherein.

FIG. 6 illustrates an example system that associates an externallydefined graphic element (EDGE) definition with the definition of a datasource.

FIG. 7 illustrates an example system for generating graphic elementsautomatically, through features or aspects described herein.

FIG. 8 illustrates an example system that facilitates instancediscovery, according to an aspect of the subject innovation.

FIG. 9 illustrates an example methodology for bi-directional binding ofgraphic elements to industrial automation data.

FIG. 10 illustrates an example methodology for associating an EDGE witha data source of an industrial automation environment.

FIG. 11 illustrates an example methodology for automatically generatinggraphic elements according to aspects of the subject disclosure.

FIG. 12 illustrates a block diagram of a computer operable to executethe disclosed architecture.

FIG. 13 illustrates a schematic block diagram of an example computingenvironment.

DETAILED DESCRIPTION

The subject disclosure is now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding thereof. It may be evident, however, that the subjectdisclosure can be practiced without these specific details. In otherinstances, well-known structures and devices are shown in block diagramform in order to facilitate a description thereof.

As used in this application, the terms “component,” “system,”“platform,” “controller,” “terminal,” “station,” “node,” “interface,”“editor,” are intended to refer to a computer-related entity or anentity related to, or that is part of, an operational apparatus with oneor more specific functionalities, wherein such entities can be eitherhardware, a combination of hardware and software, software, or softwarein execution. For example, a component can be, but is not limited tobeing, a process running on a processor, a processor, a hard disk drive,multiple storage drives (of optical or magnetic storage medium)including affixed (e.g., screwed or bolted) or removably affixedsolid-state storage drives; an object; an executable; a thread ofexecution; a computer-executable program, and/or a computer. By way ofillustration, both an application running on a server and the server canbe a component. One or more components can reside within a processand/or thread of execution, and a component can be localized on onecomputer and/or distributed between two or more computers.

Components as described herein can execute from various computerreadable storage media having various data structures stored thereon.The components may communicate via local and/or remote processes such asin accordance with a signal having one or more data packets (e.g., datafrom one component interacting with another component in a local system,distributed system, and/or across a network such as the Internet withother systems via the signal). As another example, a component can be anapparatus with specific functionality provided by mechanical partsoperated by electric or electronic circuitry which is operated by asoftware or a firmware application executed by a processor, wherein theprocessor can be internal or external to the apparatus and executes atleast a part of the software or firmware application. As yet anotherexample, a component can be an apparatus that provides specificfunctionality through electronic components without mechanical parts,the electronic components can include a processor therein to executesoftware or firmware that provides at least in part the functionality ofthe electronic components. As further yet another example, interface(s)can include input/output (I/O) components as well as associatedprocessor, application, or Application Programming Interface (API)components. While the foregoing examples are directed to aspects of acomponent, the exemplified aspects or features also apply to a system,platform, interface, controller, terminal, and the like.

As used herein, the terms “to infer” and “inference” refer generally tothe process of reasoning about or inferring states of the system,environment, and/or user from a set of observations as captured viaevents and/or data. Inference can be employed to identify a specificcontext or action, or can generate a probability distribution overstates, for example. The inference can be probabilistic—that is, thecomputation of a probability distribution over states of interest basedon a consideration of data and events. Inference can also refer totechniques employed for composing higher-level events from a set ofevents and/or data. Such inference results in the construction of newevents or actions from a set of observed events and/or stored eventdata, whether or not the events are correlated in close temporalproximity, and whether the events and data come from one or severalevent and data sources. Typically, the term “data source” used hereincan include a generalization of a controller or most any device (e.g.,industrial automation device) capable of providing its data typedefinitions.

In addition, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom the context, the phrase “X employs A or B” is intended to mean anyof the natural inclusive permutations. That is, the phrase “X employs Aor B” is satisfied by any of the following instances: X employs A; Xemploys B; or X employs both A and B. In addition, the articles “a” and“an” as used in this application and the appended claims shouldgenerally be construed to mean “one or more” unless specified otherwiseor clear from the context to be directed to a singular form.

Various aspects or features will be presented in terms of systems thatmay include a number of devices, components, modules, and the like. Itis to be understood and appreciated that the various systems may includeadditional devices, components, modules, etc. and/or may not include allof the devices, components, modules etc. discussed in connection withthe figures. A combination of these approaches also can be used.

FIG. 1 is a diagram that illustrates a bi-directional mechanism forbinding human machine interface (HMI) graphic element definitions tocontroller data types. In doing so, a user can initiate interactionswith either the graphic element definition or the controller data typeto facilitate data searching and/or filtering of the corresponding item.The control system includes a control environment 110 and a renderingenvironment 120 that utilize a binding component 130. Typically, thebinding component 130 can be distributed amongst control environment 110and rendering environment 120; the binding component 130 can includecomponent(s) in design or runtime in control environment 110, andcomponent(s) in design or runtime in rendering environment 120. Thecontrol environment 110 is functionally coupled to equipment 140 andassociated process(es) (e.g., industrial process(es), manufacturingprocess(es), measurement process(es) in a laboratory, infrastructuredevelopment process(es), such as oil and gas prospecting and extraction,etc.). Equipment 140 generally is specific to a production process andrelated market space(s) (e.g., beverages, edible goods, textile goods,oil and gas, etc.) and can include one or more sets of tools, a group ofmachines, numerous systems and related sub-systems, real estate andassociated infrastructure, and so forth. Control environment 110comprises controller(s), device(s), interface(s), machine-executablecontrol code (also referred to as control code), control datastructures, server(s), repository(ies), or the like, that control theoperation of equipment 140. Further, the rendering environment 120comprises terminal(s), device(s), interface(s), server(s),repository(ies), or the like that display industrial automation data.

A controller in control environment 110 can be embodied in one of aprogrammable automation controller (PAC), which can be a dedicatedprogrammable logic controller (PLC); a PC-based controller; or the like.Control code and control data structures in the control environment 110represent control logic that administers equipment 140, and relatedprocesses, functionally coupled to the control environment 110. In anaspect, control environment 110 is an industrial automation controlenvironment and the control logic is automation control logic. Controlenvironment 110 includes a design environment in which control logic isdeveloped and a runtime environment in which the control logic isimplemented (e.g., executed). In the design environment, in an aspect,instruction(s), data type(s), and metadata tag(s) that comprise controlcode are produced and retained as part of configuration, or composition,of a control project. Likewise, rendering environment 120 includes adesign environment and a runtime environment; the design environmentenables generation of operator interfaces than can render informationassociated with the entities or processes regulated via the controlenvironment 110.

According to one embodiment, the binding component 130 enables thedefinition of a graphic element, for example, an externally definedgraphic element (EDGE), to be utilized against a broader set of datatypes. Typically, the binding component 130 provides “Type Mappings”that enable alternative data types to be employed as bindings forproperties of an EDGE definition, for example, specified by a designer.Moreover, the EDGE can employ both a primary data type defined by theproperty in the EDGE definition and the data type(s) defined in the typemappings. Accordingly, the binding component 130 provides additionalflexibility for both the designer of the EDGE definition (e.g., who caninclude type mappings as part of the EDGE) and the end user/customer(e.g., who can define additional type mappings relative/customized tohis system). Although one or more embodiments disclosed herein refer toEDGEs, it can be appreciated that the embodiments can be applied to mostany graphic element and are not limited to EDGEs. As an example, thegraphic element can include an icon, an animated image, a sound file orother aural indicia, a screen or display, a faceplate, a navigationpanel, or the like.

FIG. 2 illustrates an example industrial control system 200 that enablesand exploits mapping graphic element definitions to controller datatypes, in a control system in accordance with aspects disclosed herein.Terminal 210 can be part of a rendering environment (e.g., 120) withinthe control system 200 and can include a set of components that enable,at least in part, the functionality of displaying an instance of thegraphic element and a bound tag. In example system 200, terminal 210 iscommunicatively coupled to a controller 250 via access network(s) 245.In an aspect, the access network(s) 245 can be geographicallydistributed and can include one or more of a wireline network or awireless network that operate in accordance with one or moreprotocols—for example, packet-based protocols such as internet protocol(IP), transmission control protocol (TCP), Ethernet, Ethernet TCP/IP,Control and Information Protocol (CIP) also referred to as Ethernet/IP,X.25, Asynchronous Transfer Mode (ATM) protocol, frame-based protocolssuch as frame relay, and circuit-switched protocols) include servicenetwork(s) and control network(s).

Controller 250 is part of a control environment (e.g., 110) within thecontrol system, and includes a control platform 254 that enables thecontroller 250 to regulate equipment (e.g., 140) and associatedprocess(es) in accordance with control code retained in control logicstorage 268, also referred to as control logic 264. Control data relatedto regulation of the associated process(es) can be retained in datastorage 272; other data also can be retained in data storage 272. Thecontrol code is based on one or more control data structures that arepart of a set of control data structures available to program thecontroller 250. The set of control data structures is extensible andspecific to controlled equipment and related process(es). In an aspect,a control data structure comprises a control instruction, a data type,and a memory tag. As an example, a memory tag, or tag, can be acomposite data structure that includes (a) metadata (e.g., tag metadata)that defines the data related to the memory tag and (b) a data value(s).Control data structure(s) storage 270 retains control data structure(s).Typically, the data type includes at least one of various common typesemployed in control systems, such as numerical data (real data, integerdata, complex data, etc.) and logical data, character data, in additionto user defined data types such as array (vectors, matrices, etc.) datatypes or composite data types, e.g., a data type with a logical variableand an array data type. In one aspect, these control data structures arebound (e.g., mapped/linked) to one or more properties of a graphicelement (e.g., EDGE) definition.

Controller 250 also includes input/output (I/O) interface(s) 258 thatenable generation of the control code. I/O interface(s) 258 also allowscommunication amongst the controller 250 and terminal 210 and thecontroller 250 and device(s), such as sensor(s) (not shown); suchcommunication effected in part through access network(s) 245. In anaspect, at least one I/O interface of I/O interface(s) 258 is associatedwith a group of I/O module(s) that can be retained in memory 266 as oneor more sets of computer-executable code instructions (not shown). Thegroup of I/O module(s) enables the at least one I/O interface, and thuscontroller 250, to communicate and control I/O functionality (which canbe defined in the group of I/O modules). In addition, controller 250includes processor(s) 262, memory 266, and other circuitry that enablesimplementation of control process(es) (e.g., execution of control logic,or control code instructions) related to a specific equipment (e.g.,140). In one or more embodiments of the subject disclosure, controller250 is an industrial controller or an industrial automation controller.Generally, industrial controllers or industrial automation controllersare purpose-specific processing devices employed to regulate automatedor semi-automated entities such as industrial processes, machines,manufacturing equipment, plants, or the like. A typical industrialcontroller or automation controller executes, through a processor(s)262, for example, control logic to measure one or more variables orinputs representative of a status of a controlled entity, or effectuateoutputs associated with control of the entity. Such inputs and outputscan be digital or analog; inputs and outputs are not shown in FIG. 2 forthe sake of simplicity.

In example system 200, terminal 210 includes a display component 218that presents an instance of the graphic element (e.g., EDGE) with anassociated tag value, for example, received from the controller 250.Typically, the definition of the graphic element (e.g., EDGE) can bemapped with one or more data types associated with the controller 250.In an aspect, the type mapping described herein can be generated onetime (e.g., at a time terminal 210 is manufactured or provisioned), forexample, by employing the binding component 130, and it can be utilizedat runtime (control runtime, rendering runtime, or both) to create avariety of collections of display objects based on control logic, asdescribed hereinbefore. In one aspect, the type mapping can be retainedin the binding component 130. Although the binding component 130 isillustrated to reside within the terminal 210, it can be appreciatedthat the binding component 130 can reside outside the terminal 210, forexample, on most any server/memory within system 200 or withincontroller 250. As an example, the type mapping can link a property inthe definition of a graphic element (e.g., an icon, an animated image, ascreen or display, a faceplate, navigation panel) to the data type. Inone aspect, a definition editor 216 can be utilized to modify propertytypes on the definition of the graphic element (e.g., EDGE definition)as well as the internal elements within the definition. Moreover, thedefinition editor 216 can be employed to define controller data types asproperties of the definition. Typically, when defining bindings in theinternal elements of the graphic element, a browser component 220 thatcan provide a data type browser can be utilized by the definition editor216 to locate the appropriate members of structure. In one aspect, thebrowser component 220 can provide the ability to browse data types,graphic element definitions (e.g., EDGEs), tags, and/or graphic elementinstances (e.g. elements on screens). Further, the definition editor 216can provide various functions, such as, but not limited to, design-timevalidation to identify binding problems, Intelli-sense, look-ahead,and/or auto-fill, verification and/or validation, ename tracking and/orpropagation, run-time binding verification, etc.

An available collection of graphic elements (e.g., EDGEs) for a specificproduct/project associated with controller 250 can be obtained bydisplay component 218, wherein the display component 218 can generate arendering project based at least on such collection. Display component218 can execute the rendering project to produce an operator interface;in an illustrative aspect, display component 218 can exploitprocessor(s) 224 to execute the rendering project. The operatorinterface so generated is thus based at least on the control logicexecuted by controller 250. In addition, display component 218 canenable data entry from an end user (e.g., a customer, a control engineeror operator); for example, display component 218 can receive data inputthrough various user-interface interaction modalities (speech gestures,motion gestures, touch gestures, etc.) and conduits, for example,keyboards, keypads, touch screens, microphones, cameras, or the like.

One or more operator interfaces generated as described herein enableterminal 210 to render control data associated with various controlprocesses regulated through controller 250 based on specific controlcode. The display component 218 in terminal 210 can render the one ormore operator interfaces through visual or aural indicia. The one ormore operator interfaces can be associated with one or more sets ofcontrol screens, and rendered in accordance with at least one of graphicdisplay object(s) or gesture rendering object(s) that compose thecontrol screen(s) in the one or more sets of control screens. Variousschemes can be employed to render the one or more operator interface(s)or other content(s) such as window-based schemes, e.g., iconicrepresentation, pop-up representation of indicia; or text-basedrepresentation, with scroll-down or scroll-sideways delivery, or staticrendering. In addition, the one or more operator interfaces or othercontent(s) can be organized in various configurations within a renderingarea (e.g., display screen) that can be a part of display component 218.

In terminal 210, at least a portion of I/O interface(s) 226 enablesfunctional coupling, e.g., communicative coupling, of terminal 210 withaccess network(s) 245; the functional coupling allows communication(e.g., exchange of data and signaling) of terminal 210 with othercontroller(s) (e.g., controller 250); other terminal(s) such as terminal280 and terminal 290; device(s), such as device 292; and/or server(s)(not shown). In an aspect, device 292 is functionally coupled to accessnetwork 245 via interface(s) 295, and includes at least one control datastructure retained in memory element 294. In addition to control datastructure(s) 294, device 292 also includes data storage (not shown). Inan embodiment, device 292 can be an intelligent device, such as avariable speed drive for a motor or an intelligent valve. In anotherembodiment, device 292 can be an I/O device, such as various sensors, ascanner, a key pad, a touch pad, or the like. In one or moreembodiments, device 292 can include at least one data structure, otherthan a control data structure, that can be exploited to automaticallygenerate an operator interface in accordance with aspects describedherein. Device 292 can be part of equipment 140.

The portion of I/O interface(s) 226 that enables communication ofterminal 210 with other terminal(s), controller(s), or server(s) viaaccess network(s) 245 can include network adaptor(s), port(s), referencelink(s), or the like. I/O interface(s) 226 also can functionally couple(e.g., communicatively couple) the terminal 210 with peripheral devices(e.g., device 292) and with an electric grid that can supply power foroperation of the terminal 210. To at least that end, I/O interface(s)226 can include a set of connectors and suitable circuitry(transformers, power amplifiers, etc.). In an aspect, I/O interface(s)226 can be distributed and deployed in part within display component 218to enable acquisition of data in response to conveyance of control datathrough one or more operator interfaces. The portion of I/O interface(s)226 that is part of display component can be embodied in data entrycomponents, e.g., keypad, touch detection components, and relatedcircuitry that enables functional coupling of the portion of I/Ointerface(s) 226 with one or more components or functional elements(e.g., processor(s), memory, bus) of terminal 210.

In example system 200, terminal 210 also includes processor(s) 224,which can be configured to execute or can execute computer-executablecode instructions (not shown) stored in memory 228 to implement orprovide at least part of the described functionality of terminal 210.Such computer-executable code instructions can include program modulesor software or firmware applications that implement specific tasks whichcan be accomplished, for example, through one or more of the methodsdescribed in the subject specification and that are associated, at leastin part, with functionality or operation of example system 200. Memory228 also can retain data resource(s) retrieved or received at least fromcontroller 250 or other controller(s) (not shown). In addition to, or aspart of, stored data resources, memory 228 also can retain stateinformation (e.g., alarm condition(s)) associated to a terminal, acontroller, a device, or other equipment. In an aspect, memory 228 caninclude various graphic elements (e.g., EGDGEs) definitions or gesturedata object definitions.

Referring now to FIG. 3, there illustrated is an example system overview300 of the resources in a project and its associated product and projectlibraries. As discussed supra, the display component 218 presents aninstance of a graphic element, such as, but not limited to, an EDGE. Inone aspect, an EDGE can be most any graphic element developed by anexternal group, for example, a third-party, an original equipmentmanufacturer (OEM), etc., via a configuration component 318. Moreover, aconsistent architecture for both EDGE and user-defined graphic elements(UDGE) is provided herein. It can be appreciated that the EDGE propertyand data type concepts disclosed herein can apply to most any type ofgraphic elements (e.g., EDGE and/or UDGE). Typically, library 302includes definitions, for example an EDGE definition 304, which is adefinition of an EDGE in an element browser. In one example, the library302 can include a product library 314 and/or a project library 316 thatcan store graphic element(s) and/or data specific to a product and/or aproject respectively. Typically, the library 302 can be included withinmemory, for example memory 228 residing within terminal 210 or memoryresiding within a server, external to, but communicatively coupled withterminal 210.

The EDGE definition 304 can include at least one property that is adiscrete (scalar or complex) type exposed by the EDGE definition to itsusers. In one aspect, the property value can be set by the user when anEDGE instance 306 is created on a screen 308. The user can set (e.g.,via the binding component 130) the property value to either a fixedvalue or can bind (e.g., via the binding component 130) the propertyvalue to a dynamic value, such as, but not limited to a controller Tagand/or another EDGE instance on the same screen. Typically, theproperties can be either required or optional. In one aspect, acontroller data type 310 can be used in an EDGE definition 304 as thetype of a property. In one example, the binding component 130 can beutilized to link the controller data type 310 with the EDGE definition304. In general, a designer (e.g., third party) of the EDGE definition304 does not know the full range or potential uses for the EDGEdefinition 304. Moreover, the end user can employ the EDGE definition304 from the OEM (or other library provider) for data types that arespecific to the end user's project. Most often, the designer is unawareof these intended projects in which the EDGE can be utilized. To supportthis scenario, the types used by properties in the EDGE definition 304can be extended by users of it, but in a manner such that the EDGEdefinition remains intact. In one aspect, “Type Mappings” are utilizedfor binding data types 310 to properties of the EDGE definition 304, forexample, by employing the binding component 130. This enables thedefinition 304 of a single EDGE to be used against a broader set of datatypes 310. Moreover, the type mappings do not impact the visual layoutbecause bindings in the visual layout can only refer to properties ofthe EDGE definition 304; they are isolated from the details of themappings. In one embodiment, the data type 310 can be a structure; forexample, a complex type. Moreover, the data type 310 definition caninclude system-defined, user-defined, Add-On Instruction (AOI)-defined,and/or module-defined data types, as explained in detail infra.

Properties can define the interface (e.g., a collection of propertiesthat an EDGE exposes to its users) of the EDGE definition 304 to a user.In one aspect, the properties of the EDGE definition 304 can be extendedin various areas, for example, property types can include controllerdata types and/or additional flexibility. Typically, strongly-typedproperties are provided for complex data structures or scalars. Further,loosely-typed properties are provided for scalar types (e.g., anyNum).Furthermore, un-typed properties are provided for deferred connectivityand/or parameter substitution. In one example, meta-information thatdesignates a property as “required” or “optional” to support design-timevalidation and/or conditional bindings in the EDGE definition 304 canalso be provided. In another example, meta-information that provides ahint/indication that the property is intended to be bound to a live datavalue can be provided. Additionally, the EDGE definition 304 can supportmultiple complex properties (e.g., multiple controller data types). Whendoing so, the user can select/set a default binding for one propertythat references another property (e.g., via the binding component 130).

According to an aspect, during run time, an EDGE instance 306 can bedisplayed on various screens 308 for displaying data from a tag 312. Inone example, when the EDGE definition 304 is instantiated 306, the datatype in a strongly-typed property must exactly match the data type ofthe bound tag 312. Using strongly-typed properties provides the greatestopportunity for an integrated design-time experience. For example,strongly-typed properties enable design-time features for the EDGEdefinition 304, such as, but not limited to, Intelli-sense, look-ahead,and/or auto-fill, verification and/or validation, rename tracking and/orpropagation for data types 310 and their members. In scenarios where thedesigner of the EDGE definition 304 and the end user of that EDGE aremore decoupled, the end user may want to use the EDGE in a screen 308,but the data types of the EDGE it are not a good fit for the currentproject 320, product or system. In such a case, the type mappingmechanisms described herein can be used to map between types.Alternatively, the EDGE designer can select to use loosely or un-typedproperties to provide additional flexibility. In another example, whenthe EDGE definition 304 is instantiated 306 in the design-time ordisplayed on a screen 308 in the run-time, the system must verify thatthe conversion from data type in the bound tag 312 to the data type 310in the property is valid. The design-time provides the ability for earlyvalidation and/or feedback for the user, but is not the final authorityon whether or not the conversion is valid. The final decision occurs inthe run-time system to validate that the on-line tag value can beappropriately converted.

Loosely-typed properties can generally be utilized for scalar data typesand do not apply to complex or structured types. Typically,loosely-typed properties provide greater flexibility in supporting arange of data types. However, when multiple property bindings areneeded, multiple, scalar bindings would need to be created, rather thanemploying a structure. Generally, use of loosely-typed properties iswell suited for simple, scalar values, but is not the recommendedapproach for complex or structured types. Many of the benefits forstrongly-typed properties are not available on the EDGE definition 304because the type of the binding is not known until instantiation time.In addition, un-typed properties can be utilized to support stringsubstitution. This allows a parameter value to be expanded to completethe connection to external data. Though again, all of the above notedbenefits realized by strongly-typed properties are lost when using thisapproach. Much like loosely-typed properties, enhanced features on theEDGE definition 304 are not available because the type of the binding isnot known until instantiation time.

According to one aspect, the EDGE definition 304 can support multipledata types 310. Consider the following example to better illustrate someof the user interactions and how the disclosed architecture supportsthem. In this example case, the user designed EDGE definition 304 canhave several complex properties based on structured data types 310:

<Typedef id=“TemperatureLoop” baseType=“Group”> <meta:displayName>Temperature Loop with AutoTuneStuff</meta:displayName>  <Properties>   <Property id=“dataPIDE”type=“PID_ENHANCED”>    <meta:displayName>Temperature Loop PIDETag</meta:displayName>    <meta:category>General</meta:category>   <meta:connectionOnly>true</meta:connectionOnly>   <meta:required>true</meta:required>   </Property>   <Propertyid=“autoTune” type=“PIDE_AUTOTUNE” src=“dataPIDE.@AutoTune” >   <meta:displayName>PIDE Auto Tune Tag</meta:displayName>   <meta:category>General</meta:category>   <meta:connectionOnly>true</meta:connectionOnly>    <!-- Omitting therequired element means that it is optional   <meta:required>false</meta:required>    -->   </Property>   <!-- ...-->  </Properties> </Typedef>It can be appreciated that the example extensible markup language (XML)code utilized herein is simply one example and that the subjectspecification is not limited to utilizing XML. The above example EDGEdefinition 304 is designed with multiple properties for: (i) the tag ofan enhanced proportional-integral-derivative (PIDE) loop (dataPIDE)which is “required;” and (ii) the AutoTune tag of the PIDE loop(autoTune) which is “optional.” By default, the autoTune tag isretrieved from the meta-data of the dataPIDE loop Tag itself. If thePIDE loop does not have that meta-data configured, then the user canmanually configure the binding of the autoTune tag. The instance 306 ofthe EDGE can be created on a screen 308, as follows:

<TemperatureLoop name=“TempLoop_201”> <dataPIDE>{::Controller_1\PIDE_201}</dataPIDE>  <!-- Binding to theautoTune property defaults to using the value in:  <autoTunetype=“PIDE_AUTOTUNE”>{::Controller_1\PIDE_201.@AutoTune}</autoTune>  --></TemperatureLoop> <TemperatureLoop name=“TempLoop_202”> <dataPIDE>{::Controller_1\PIDE_202}</dataPIDE> <autoTune>{::Controller_1\GlobalAutoTuneTag}</autoTune></TemperatureLoop>

As can be seen above, the example EDGE definition 304 includes onerequired and one optional property. The required versus optionaldesignation serves several purposes, for example, provides a cue for thedesign-time validation system to identify binding problems, and/orprovides the mechanisms for the designer of the EDGE definition 304 todevelop conditional visualizations based on whether the property isbound or not. Typically, optional properties can necessitate additionalconstructs for the designer of the EDGE definition 304 to make decisionsbased on a property's binding. In other words, the property binding canbe set or null, a valid type or an invalid type, a temporarily invalidor with bad quality (e.g., due to a transient communication error).Accordingly, in the above example, the visual layout can haveconditional bindings such as:

<View>  <!-- ... -->  <Button id=“LaunchAutoTuneView” >   <SetPropertyref=“visibility”    src=“{(autoTune != null) && (autoTune.@Quality ==Quality.    Good)}” />   <!-- ... -->  </Button>  <!-- ... --> </View>

In one aspect, a user can also configure (e.g., via the bindingcomponent 130) type mappings for the PID_ENHANCED and PIDE_AUTOTUNEtypes. Moreover, if any data type that supplies the required data fieldsis to be supported, an un-typed type mapping (or an un-typed property ifconfigured in the EDGE properties) can be utilized, as follows:

<TypeMappings>  <TypeMap to=“PID_ENHANCED” from=“anyType” />  <TypeMapto=“PIDE_AUTOTUNE” from=“anyType” /> </TypeMappings>The above type mappings enable binding any structure that supports thefields of the PIDE used in this example EDGE definition 304. Typically,the type mappings provide support for un-typed data for the EDGEdefinition 304. This means that the EDGE definition 304 can be used withany tag 312 that supports the SP, PV, etc. fields used in the EDGEdefinition 304 and visuals. This provides added flexibility at the costof deferring validation and verification to the run-time. In addition,strongly-typed mappings are also supported.

<TypeMappings>  <TypeMap to=“PID_ENHANCED” from=“MyTempLoopAOI”>   <Mapto=“PID_ENHANCED.PV” from=“{MyTempLoopAOI.mySpecialPV}” />   <Mapto=“PID_ENHANCED.SP” from=“{MyTempLoopAOI.mySpecialSP}” />   <!-- ...-->  </TypeMap>  <TypeMap to=“PIDE_AUTOTUNE” from=“MyTempLoopAOI”>  <Map to=“PIDE_AUTOTUNE” from=“{MyTempLoopAOI.@AutoTuneInOutParam}” />  <!-- ... -->  </TypeMap> </TypeMappings>The above type mappings enable binding to a Add-On Instruction (AOI)definition that has different parameters than a PIDE loop structure.This type mapping binds to an InOut parameter of the AOI. In thisexample, the AOI includes an InOut parameter where the user can pass inan AutoTune tag. The InOut parameter is accessed via the meta-data ofthe AOI. When all the type mappings are defined, the example EDGEdefinition 304 can be utilized with (i) PID_ENHANCED—an enhanced PIDEand its autotune Tag; (ii) anyType—an un-typed property to be used withany complex type with the specified bindings; and/or (iii)MyTempLoopAOI—a custom Add-On instruction, as shown below:

<TemperatureLoop name=“TempLoop_203”>  <dataPIDEtype=“anyType”>{::Controller_1\Supports_PIDE_Members}</dataPIDE> <autoTunetype=“anyType”>{::Controller_1\Supports_AutoTune_Members}</autoTune></TemperatureLoop> <TemperatureLoop name=“TempLoop_204”>  <dataPIDEtype=“MyTempLoopAOI”>{::Controller_1\MyTempLoopAOI_204}</dataPIDE>  <!--Binding to the autoTune property defaults to using the value in:<autoTunetype=“PIDE_AUTOTUNE”>{::Controller_1\MyTempLoopAOI_204.@AutoTuneInOutParam}</autoTune>  --> </TemperatureLoop>

In another example, a valve can be represented by a simple EDGE thatcorresponds to an AOI. Moreover, the AOI can be the definition of thecontrol logic and the EDGE can be the definition of the HMIvisualization. In one aspect, the EDGE definition can provide an abilityto specify more than one visualization for an EDGE. For example,visualizations can be displayed for an icon, overview, and/orconfiguration of the EDGE. In yet another example, EDGE definition 304can be defined, via configuration component 318, such that, the EDGEdefinitions 304 can connect with many data values from many differentdata types, and/or be built as composites of other EDGEs. For example, atank overview can be developed as an EDGE, wherein data is drawn fromthe primary tank of interest, secondary tanks/silos containing materialfeeds, and individual equipment such as valves and pumps. Typically,many, if not all of these items, are typically modeled with a data typefor each item (e.g., Tank_UDT, Silo_UDT, ValveAOI, etc.). In anotherexample, a conveyor can be developed as a composite EDGE with multipleconnections.

According to an aspect, several scenarios related to creating EDGEinstances on a screen can be provided by system 300. In one aspect, auser (e.g., via terminal 210) can drag the EDGE definition 304 from anelement library (e.g., product library 314 and/or project library 316)to a screen 308. Typically, when the EDGE definition 304 is dropped ontothe screen, a filtered list of tags 312 that match the EDGE's propertiescan be displayed (e.g., via display component 218). In one embodiment, asearch component 322 can be utilized search the project database (e.g.,including product library 314 and/or project library 316) for the tags312 that match the EDGE's data type 310.

In another aspect, the user (e.g., via terminal 210) can drag a tag 312from a tag browser (not shown) to the screen 308 and, when the tag 312is displayed on the screen 308, a filtered list of EDGE definitions 304that match (are bound to) the tag's data type 310 can be presented to auser (e.g., via display component 218). Additionally or alternatively,the element library (e.g., product library 314 and/or project library316) can be filtered based on a data type 310 and/or a tag 312 for theselected EDGE definition 304. In other words, when instantiating an EDGEdefinition 304, only those tags 312 are displayed that can be used withthat EDGE. Further, when searching for/selecting a tag 312, a list ofall of the EDGE definitions 304 that can be utilized with that tag 312can be displayed along with the tag 312.

FIG. 4A illustrates an example instance of a graphic element 400, forexample, an EDGE representing a gauge in an industrial control system.In an example, the gauge can be monitored/controlled by controller 250and the instance of the gauge can be displayed on terminal 210, bydisplay component 218. It can be appreciated that the gauge is simplyone example and the subject innovation is not so limited. The followingpseudo XML code example is intended to show the major aspects of EDGEdefinitions and instances in accordance with an aspect of the subjectinnovation. The type definition for the gauge EDGE can be described asfollows:

<Typedef id=“SimpleGauge” baseType=“Group”>  <meta:displayName>A SimpleGauge EDGE</meta:displayName>  <meta:description>This Gauge uses acomplex property.</meta:  description>  <!-- ... --> </Typedef>In the above example, the gauge EDGE extends a base Group GraphicElement definition.

In one aspect, properties define the interface of the EDGE definition toits users. When an instance of an EDGE is created on the screen (andselected in the designer), its public properties are available forediting in a property pane (e.g., via the definition editor 216). EachEDGE property has a set of core attributes defined by a run-time datamodel. For example, the core attributes can include an Identifier (e.g.,a localized name of the property), a type (e.g., an expected type ofproperty), and/or a value (e.g., a default value of the property whenthe user does not specify a value (or when a bound value is notaccessible in the run-time)). Each EDGE property can also havemeta-information applied to it to support editing behavior in thedesign-time user interface (typically in the property pane). Themeta-information can include, but is not limited to, a display name(e.g., a localized name of the property), a description (e.g., alocalized description of the property), a category (e.g., a propertypane category/group in which to display the property), a required oroptional designation on the property (e.g., defaults to optional),and/or an indication that the property is intended to be bound to a livedata value.

Typically, an EDGE designer can choose whether to expose complex orsimple (scalar) values for each property. In one case, a property can beconfigured as a complex value for a controller data type. Alternatively,a set of simple properties for the various members of a complex datatype can be exposed. For example, with respect to the gauge EDGE 400, adesigner of the gauge EDGE 400 can decide that all of the internals ofthe Gauge element 400 are opaque and the end user cannot individuallyconfigure properties for each item. In other words, the designer candecide that all internal data is driven by a single complex propertythat connects to some external data. This approach is shown in theexample below.

<Properties>  <!-- In this example, a single numeric property to for thedata value is exposed. -->  <Property id=“dataValue” type=“anyNum”>  <meta:displayName>Gauge Data Tag</meta:displayName>  <meta:category>General</meta:category>  <meta:connectionOnly>true</meta:connectionOnly>  <meta:required>true</meta:required>  </Property>  <!-- The EDGEdesigner chose to expose some properties to configure the visual   appearance of the EDGE. -->  <Property name=“myGaugeStyle”type=“StyleEnum” value=“Simple”>   <meta:displayName>Visual Style of theGauge (Simple, Fancy, etc)</meta:displayName>  <meta:category>Layout</meta:category>  </Property>  <!-- ... --></Properties>In this example, a single numeric property (dataValue) for the datavalue is exposed. This is a loosely-typed property that can be a realdata, integer data, complex data, etc. value from a controller datatype, or a numeric value from another data source such as, but notlimited to an electronic operator interface (EOI) tag or other graphicelement.

According to an aspect, the below XML example depicts a visual layout ofthe gauge element 400. Typically, the binding statements for internaldisplay elements (shown in the curly braces syntax) in the visual layoutrefer to properties of the EDGE definition (using the propertyidentifiers). These bindings can refer to any properties in the EDGEdefinition including, but not limited to, the members of complexproperty values (e.g., controller data types).

  <View>   <!-- Ignoring all layout aspects such as width, height, x, y,etc... -->   <!-- “Area X tank pressure” -->   <TextDisplayid=“_description”>    <SetProperty ref=“fillColor”   value=“white” />   <SetProperty ref=“borderThickness” value=“3” />    <SetPropertyref=“text”  src=“{dataValue.@Description}” />   </TextDisplay>   <!--“0” on the left side of the Gauge -->   <TextDisplay id=“_min”>   <SetProperty ref=“fillColor”   value=“transparent” />    <SetPropertyref=“borderThickness” value=“0” />    <SetProperty ref=“text” src=“{dataValue.@Min}” />   </TextDisplay>   <!-- “15000” on the upperright side of the Gauge -->   <TextDisplay id=“_max”>    <SetPropertyref=“fillColor”   value=“transparent” />    <SetPropertyref=“borderThickness” value=“0” />    <SetProperty ref=“text” src=“{dataValue.@Max + ‘ ’ + dataValue.@Units}” />   </TextDisplay>  <!-- Red Gauge arror rotating according to the current value -->  <Line id=“_arrow” width=“10” color=“red” style=“solid”>   <SetProperty ref=“fgColor”   value=“red” />    <SetPropertyref=“weight”   value=“4” />    <SetProperty ref=“style” value=“solid” />   <SetProperty ref=“rotation”  src=“{(dataValue/(dataValue.@Max-dataValue.@Min))*135}”/>   </Line>   <!-- “8,5000 psi” on the bottom ofthe Gauge -->   <TextDisplay id=“_value”>    <SetPropertyref=“fillColor”   value=“Green” src=“{colorConverter(dataValue)}” />   <SetProperty ref=“borderThickness” value=“1” />    <SetPropertyref=“text”  value=“” src=“{dataValue+ ‘ ’ + dataValue.@Units}” />  </TextDisplay>  </View>  <Behaviors> <Function id=“colorConverter”parameter=“arg0” type=“anyNum”>    <!-- Assume that there is a “global”Color table with at least the fields below -->    <![CDATA[     if (arg0<= arg0.@Min) return Colors.Alarm.Lo; <!-- red -->     if (arg0 >=arg0.@Max) return Colors.Alarm.Hi; <!-- red -->     return Colors.OK;<!-- green -->    ]]>   </Function>  </Behaviors>In this example scenario, the meta-data fields of the anyNum type (shownby the .@ syntax) are referenced in the bindings of the gauge element400. When the binding of the dataValue property is configured by the enduser, all of the binding expressions on the internal HMI elementssubsequently bind to the meta-data of the bound Tag.

Referring back to the drawings, FIGS. 4B-E illustrate examplescreenshots that depict editing of a visual layout of an example gaugeEDGE definition, for example, in a design-time user interface. In oneaspect, when the instance of the gauge EDGE 400 is selected, as shown bya dotted line in FIG. 4B, public properties of the EDGE definition aredisplayed in a property pane 402. Further, when an HMI element (404,408) within the EDGE 400 is selected, the properties of that element aredisplayed in respective property panes (406, 410). For example, in FIG.4C, properties, such as, but not limited to, “text,” “fill color,”“border thickness,” and “border color” associated with HMI element 408,along with values of the respective properties are displayed in propertypane 406, on selection of the HMI element 404. In another example, inFIG. 4D, properties, such as, but not limited to, “text,” “fill color,”“border thickness,” and “border color” associated with HMI element 408,along with their corresponding values are displayed in property pane410, on selection of the HMI element 408. Another useful view displayedin the editor (e.g., definition editor 216) is that of the dataValueproperty 412, as depicted in FIG. 4E. Moreover, this view can depict allthe internal properties that reference the external data type/externalproperty. As an example, this cross-referencing can be performed by thebinding component 130.

FIGS. 5A-C illustrate example screenshots that depict configuration ofproperties of an example gauge EDGE, according to an aspect of thesubject specification. In one example, when a user wants to utilize theEDGE on a screen, an instance of the EDGE is created, for example, viadrag/drop or other user interface (UI) mechanisms. Further, the user canconfigure properties of the EDGE by selecting different HMI elements ofthe EDGE. Conceptually, an instance of the gauge EDGE can be expressedas follows when bound to a controller Tag value:

  <SimpleGauge name=“Gauge_101”>  <dataValue>{::Controller_1\PressureSensor_101}</dataValue> </SimpleGauge>In the property pane 502, the dataValue property could be visualized asshown in FIG. 5A.

Internal to the EDGE, the data bindings are set based on theconfiguration of the above binding. For example, if the internal HMIelements (404, 408) are selected, as shown in FIGS. 5B-C, the resultingbindings of those HMI elements (404, 408) are displayed in therespective property panes (406, 410). As described supra, duringcreation of the EDGE definition, the full range or potential uses forthe EDGE definition are generally not known. In other words, the enduser can employ the EDGE definition for data types that are specific tothe user's project, other than the intended data types thought of by anEDGE designer during creation of the EDGE definition. To support thisscenario, in one aspect, the types employed in the properties of theEDGE definition can be extended by the end users, in a manner such thatthe EDGE definition remains intact.

Type mappings provide a mechanism for utilizing alternative data typesas bindings for properties of an EDGE definition. This enables thedefinition of a single EDGE to be used against a broader set of datatypes. That is, the EDGE can work with both a primary data type definedby a property in the EDGE definition and the alternate data typesdefined in the type mappings. This mechanism provides additionalflexibility for both the designer of the EDGE definition and the enduser. Returning to the gauge EDGE example, consider an example scenariowherein the designer of the EDGE definition wanted to support a TIMERdata type for the dataValue property (which is of anyNum type). In thisexample scenario, the designer can define a type mapping as part of theEDGE definition as follows:

<TypeMappings>  <TypeMap to=“anyNum” from=“TIMER”>   <Map to=“anyNum”from=“{TIMER.ACC}” />   <Map to=“anyNum.@Description”from=“{TIMER.@Description}”/>   <Map to=“anyNum.@Min” from=“0” />   <Mapto=“anyNum.@Max”  from=“{TIMER.PRE}” />   <Map to=“anyNum.@Units” from=“msec” />  </TypeMap> </TypeMappings>Typically, the above mapping can include several fixed values in theplace of some bindings, for example, when the data type being mappedfrom does not support all of the fields of the complex property. Inaddition, if the end user wants to utilize the gauge EDGE with a datastructure employed in his controller, a type mapping can be generated tosupport that data structures using the same gauge EDGE definition. Inthis case, the user defined type (UDT) LegacyStructWithMeta is mapped tothe anyNum data type, as follows:

<TypeMappings>  <TypeMap to=“anyNum” from=“LegacyStructWithMeta”>   <Mapto=“anyNum” from=“{LegacyStructWithMeta.value}” />   <Mapto=“anyNum.@Description” from=“{LegacyStructWithMeta.descr}” />   <Mapto=“anyNum.@Min” from=“{LegacyStructWithMeta.min}” />   <Mapto=“anyNum.@Max”  from=“{LegacyStructWithMeta.max}” />   <Mapto=“anyNum.@Units”  from=“{LegacyStructWithMeta.EU}” />  </TypeMap></TypeMappings>

In one aspect, the gauge EDGE definition's visual layout is not affectedwhen such type mappings are added. Since the bindings in the visuallayout only refer to properties of the EDGE definition, the visuallayout is isolated from the details of type mappings. In other words,the visual layout bindings cannot employ any of the type map elements.Moreover, since the type mappings extend the data types supported by theEDGE definition, visualizations in the element browser can also beextended to show the user what types are supported by a given EDGEdefinition.

The extensibility and flexibility of the type mappings is realized whenan instance of an EDGE is created on a screen. With the previouslydefined type mappings, the gauge EDGE now supports the anyNum,LegacyStructWithMeta and TIMER data types. Instances can be createdusing any of these types. For example,

<SimpleGauge name=“Gauge_102”>  <dataValuetype=“LegacyStructWithMeta”>{::Controller_1\LegacyStruct_102}</dataValue></SimpleGauge>

TABLE 1 Property Value dataValue {::Controller_1\LegacyStruct_102.value}@Description {::Controller_1\LegacyStruct_102.descr} @Min{::Controller_1\LegacyStruct_102.min} @Max{::Controller_1\LegacyStruct_102.max} @Units{::Controller_1\LegacyStruct_102.EU}

<SimpleGauge name=“Gauge_103”>  <dataValuetype=“TIMER”>{::Controller_1\Timer_103}</dataValue> </SimpleGauge>

TABLE 2 Property Value dataValue {::Controller_1\Timer_103.ACC}@Description {::Controller_1\Timer_103.@Description} @Min 0 @Max{::Controller_1\Timer_103.PRE} @Units msec

It can be appreciated that, although the above example gauge EDGEutilizes a complex property, several simple properties can also beexposed for configuration by the end user. For example, the defaultbindings of the simple properties can employ meta-data from one of theother properties. Using this approach minimizes the configuration of thegauge EDGE instance when bound to data that supports these meta-datafields.

Referring now to FIG. 6, there illustrated is an example system 600 forassociating an EDGE definition with the definition of a data source.Typically, graphic displays in HMI products can be associated with adata source such as, but not limited to, a controller tag variable. Inone aspect, the binding component 130 can be utilized to associate,link, bind and/or map an EDGE definition (e.g., EDGE definition 304)stored in library 302, with the definition of a data source such as, butnot limited to, a User Defined Type (UDT) or an AOI. Moreover, when aninstance 306 of the EDGE is created in an HMI configuration environment604, a designer can be prompted with a selection of suitable datasources (606-610) from a pre-configured program file.

Further, a population component 602 can be utilized to populate theinstance of the EDGE with information to access data value fields thatare stored and sourced by a data source (606-610), associated withproperties of the EDGE definition. By associating an EDGE definitionwith data source type information such as UDT or AOI fields, theconfiguration of an instance 306 of EDGE is simplified, reducing thepopulation of suitable data source fields from “what ever is configured”to “only instances of the associated data source type.” This also makesit possible to employ an EDGE as a data source inspector, selecting fromamong a set of data items of the particular type of data sourceassociated with the EDGE definition. In one aspect, associating EDGEdefinitions with data source type information makes it easier to builddomain-specific automation design content, connecting logic in theprogram file with Graphic Element content in a Configuration file.

FIG. 7 illustrates a system for generating graphic elementsautomatically, in accordance with an aspect of the subject innovation.Typically, terminal 210 can be coupled to an industrial automationdevice 702 (e.g., controller 250) via a wired and/or wireless accessnetwork 245. In one aspect, the terminal 210 can be programmed with anHMI application 704, for displaying content contained in the HMIapplication 704. Moreover, the system 700 enables a user to selectinformation from the industrial automation device 702 that can bedisplayed on the terminal 210. As an example, the HMI application 704can be new, e.g., previously un-programmed, and system 700 canfacilitate generation of a set of screens in the HMI based on the datain the industrial automation device 702.

According to an embodiment, a graphics generation component 706 can beutilized to automatically create an application that represents logicwithin the industrial automation device 702. In one aspect, the graphicsgeneration component 706 can detect connection of the industrialautomation device 702, for example, via the access network 245. Further,the graphics generation component 706 can identify the data from theindustrial automation device 702 and determine a graphic element and/orfaceplate from the HMI application 704 that is best suited to representthe data. In an automatic mode (e.g., when a user selects an “autocreate” option), the terminal 210 can create an application that bestrepresents the logic in the industrial automation device 702, withoutrequesting and/or receiving user input. For example, a discoverycomponent 710 can be utilized for discovery of information (e.g., logic)from the industrial automation device 702. Typically, the graphicsgeneration component 706 can identify logic based on the informationprovided by the discovery component 710 or by querying the industrialautomation device 702, and can identify a graphic element (and/orfaceplate) to represent the logic in the HMI application 704.Alternatively, in a manual mode (e.g., when a user selects a “createwith prompts” option), the graphics generation component 706 can queryand receive user input to manually select the controls and/or screengrouping that best represents the logic in the industrial automationdevice 702. Typically, the “create with prompts” option allows increasedflexibility for the user, but requires more user interaction.

In an aspect, the graphics generation component 706 can build a list ofgraphic elements that best fit the logic of the industrial automationdevice 702 and identify a recommended graphic element from the list, forexample a best/optimal graphic element. As an example, to infer the listof graphic elements, e.g., to reason and draw a conclusion based on aset of metrics, formal arguments, or known mathematical outcomes incontrolled scenarios, graphics generation component 706 can exploitvarious artificial intelligence (AI) techniques. AI techniques typicallyapply advanced mathematical algorithms or methods to a data set; suchalgorithms or methods are part of the methodology and can includedecision trees, neural networks, regression analysis, principalcomponent analysis (PCA) for feature and pattern extraction, clusteranalysis, genetic algorithm, or reinforced learning. In particular,graphics generation component 706, or one or more components therein,can employ at least one of numerous methods for learning from the dataset and then drawing inferences from models formally represented byemployed method. As an example, the numerous methods for learning caninclude Hidden Markov Models (HMMs) and related prototypical dependencymodels can be employed. General probabilistic graphical models, such asDempster-Shafer networks and Bayesian networks like those created bystructure search using a Bayesian model score or approximation can alsobe employed. In addition, linear classifiers, such as support vectormachines (SVMs), non-linear classifiers like methods referred to as“neural network” methodologies, fuzzy logic methodologies can also beemployed. Moreover, game theoretic models (e.g., game trees, gamematrices, pure and mixed strategies, utility algorithms, Nashequilibria, evolutionary game theory, etc.) and other approaches thatperform data fusion, etc., can be exploited by the graphics generationcomponent 706. In one example, the user can provide a finaldetermination on the graphic element to be utilized. In this manner, theuser can build an HMI application 704 on the terminal 210 without usinga design tool.

Additionally or optionally, a security component 708 can be utilized torestrict access to the industrial automation device 702. Althoughsecurity component 708 is depicted to reside within terminal 210, it canbe appreciated that the security component 708 can reside within theindustrial automation device 702, a disparate device (not shown) coupledto the access network 245, distributed over multiple devices, etc. As anexample, the security component 708 can verify security credentials(e.g., username, password, etc.) received from the user (or associatedwith the terminal 210) to grant/restrict access the industrialautomation device 702. Typically, most any authentication and/orauthorization technique can be utilized, including, but not limited to,biometric identification and/or verification. The security component 708can also apply restrictions on the content generated by the graphicsgeneration component 706. The HMI application 704 configured in thismanner can be saved on the terminal 210 and can be available for uploadto a desktop editing environment for further manipulation. According toone aspect, the graphics generation component 706 can also replace thecurrent contents of a configured HMI application 704 in view of theinformation received from a newly attached controller (not shown). Thesecurity component 708 can be utilized to prevent accidental ordeliberate access of this feature.

FIG. 8 illustrates an example system 800 that facilitates instancediscovery, according to an aspect of the subject innovation. The system800 enables a user to change the information in an industrial automationdevice 702, coupled to terminal 210 that includes an HMI application 704configured for the industrial automation device 702, and detects thechange without requiring a manual refresh. For example, the user canchange names, instances of a loop, etc.

According to an aspect, the change can include modifying, adding, and/ordeleting components of the industrial automation device 702. Forexample, the name of a tag in the industrial automation device 702 ischanged from “Boiler1” to “MainBoiler”. In the example case of the namechange, the update component 802 can detect that the tag name waschanged and update the HMI application 704 to reflect these changes,without a manual refresh by the user. In another example, if newcomponents are added to the industrial automation device 702, the updatecomponent 802 can determine what has changed, and then find an optimallocation in the HMI application 704 where the new graphic elementcorresponding to the new component can be added/displayed. Typically,the addition of the new graphic element can be impacted by severalfactors, such as, but not limited to, an update mode that the terminal210 is configured for, security of a user logged in at the terminal 210,configuration information supplied by a designer of the HMI 704, and thelike. As an example, the update modes can include an automatic and/or amanual update. Moreover, if the update mode is set as automatic, theupdate component 802 can identify a new graphic element(s) that can beadded and a location for adding the new graphic element(s), without (orwith minimal) user intervention. Typically, an AI technique and/or mostany optimization mechanism can be utilized to identify the new graphicelement(s) and a location that is best suited for representing thechange. Moreover, new logic identified on the industrial automationdevice 702 can be employed by the update component 802 to identify atype of graphic element that best matches/represents the logic content.This matching/representing can utilize pre-defined graphic element typesthat are available in the terminal 210. In one example, the terminal 210(e.g., via display component 218) can provide an indication of which newgraphic element was added as result of this discovery and/or theindication can be displayed until it is acknowledged. Alternatively, ifthe update mode is set as manual, then the update component 802 cannotify the user that a new component has been detected on the industrialautomation device 702 and can prompt the user to select a new graphicelement to associate with the new component and/or a location for thenew graphic.

In one aspect, if a component is deleted from the industrial automationdevice 702, the update component 802 can detect the delete and mark theassociated component for delete from the HMI application 704. Typically,the update component 802 can prompt a user to confirm delete of agraphic element associated with the deleted component (e.g., inautomatic and/or manual modes). Oftentimes, multiple changes can bedetected by the update component 802, for example, new item added,existing item deleted, and existing item renamed etc. In this examplecase, the update component 802 can automatically update the HMIapplication 704, but prompt the user for input incase of any conflictsand/or ambiguous situations. For example, if HMI application 704includes a reference to a tag called “Boiler1,” which is deleted fromthe industrial automation device 702, and two new tags, “MainBoiler” and“Boiler1,” are created on the industrial automation device 702. In thisexample situation the update component 802 can detect that a new tag iscreated for “MainBoiler” and add an appropriate graphic element to theHMI application 704. In addition, the update component 802 can query auser to determine whether the reference to the named tag “Boiler1” is tobe changed to match the new “Boiler1” tag in the industrial automationdevice 702, or whether a new graphic element is to be created. In oneaspect, when graphic elements are modified, added and/or removed, theupdate component 802 can adjust (e.g., auto-scale) the content on ascreen of the terminal to accommodate the changes.

According to an embodiment, the update component 802 can monitorequipment (e.g., industrial automation device 702) coupled to theterminal 210 continuously, periodically, and/or on-demand. In anotherembodiment the equipment can push data indicative of the change to theterminal 210. Additionally or alternatively, if the equipment isdisconnected or is not coupled to the terminal 210, the monitoring bythe update component 802 can be suspended and can be resumed as soon asthe connection is re-established. Further, in one aspect, the updatecomponent 802 can provide a visual notification on graphic element(s)that have been added, deleted or changed. Typically, this notificationcan stay on a screen until a user has acknowledged the addition orchange. In the case of a deletion, a user with verified securitycredentials (e.g., by security component 708) can be prompted to approvethe delete. Further, the update component 802 can provide, other users,a notification indicating that the delete has occurred, butacknowledgement is pending. It can be appreciated that securitycredentials can be obtained and verified (e.g., by security component708) for any change, for example, add, modify and/or delete, detected bythe update component 802, prior to applying the change.

User security data (e.g., received from security component 708) can havean impact on operation of the update component 802. For example, duringan automatic mode, all changes except delete can be performed withoutuser intervention. In the case of a delete, the update component 802requests a confirmation from a user authorized to approve the deletion.Moreover, other users (e.g., that are not authorized to approve thedeletion) that log in to HMI terminal 210 can be provided with anindication of the changes that have been made. In contrast, during themanual mode, all changes must be approved by a user with appropriatesecurity access rights. Typically, all other users can be notified thata change is pending approval, so that a user with correct securitycredentials can be notified and logged in to accept the changes.Moreover, when the authorized user logs in, the update component 802 canprompt the authorized user to confirm the changes, select new graphicelements and/or provide a location for the new graphic elements.

Typically, a setup component 804 can be utilized to configure the HMIapplication 704 in the design time environment to identify a level ofinstance discovery. As an example, the setup component 804 can beincluded within a design time client tool. Moreover, a designer canutilize the setup component 804 to control a scope of an instancediscovery feature, for example, disable instance discovery for theapplication 704, enable or disable at a screen level based on the scopein the industrial automation device 702, and/or configure a screen toadapt based on a tag type. Limiting instance discovery based on scope inthe industrial automation device 702 allows for a single industrialautomation device 702 to have many nodes. For example, a singlecontroller can control two assembly lines. A first screen of theapplication 704 can be associated with tags of the first assembly lineand a second screen of the application 704 can be associated with thesecond assembly line. In this manner, if new logic components are addedto the second line, only the second screen will be updated (e.g., byupdate component 802. In addition, the setup component 804 can specifywhether the application 704 can pre-identify a best/optimal/preferredchoice when a type of logic component is encountered on the industrialautomation device 702. Further, the setup component 804 can also providean update frequency or time that the update component 802 can query theindustrial automation device 702 for changes.

In view of the example systems described above, example methods that canbe implemented in accordance with the disclosed subject matter can bebetter appreciated with reference to flowcharts in FIGS. 9-11. Forpurposes of simplicity of explanation, various methods disclosed hereinare presented and described as a series of acts; however, it is to beunderstood and appreciated that the subject disclosure is not limited bythe order of acts, as some acts may occur in different order and/orconcurrently with other acts from that shown and described herein. It isnoted that not all illustrated acts may be required to implement adescribed method in accordance with the subject specification. Inaddition, for example, one or more methods disclosed herein couldalternatively be represented as a series of interrelated states orevents, such as in a state diagram. Moreover, interaction diagram(s) orcall flow(s) represent several of the example methods disclosed hereinin accordance with the described subject matter; particularly ininstances when disparate entities, or functional elements, enactdisparate portions of one or more of the several methods. Furthermore,two or more of the disclosed example methods can be implemented incombination, to accomplish one or more features or advantages describedin the subject disclosure.

FIG. 9 illustrates an example methodology 900 for bi-directionallybinding graphic elements to industrial automation data, according toaspects of the subject disclosure. At 902, an EDGE definition is boundto a controller data type. Although a controller data type is describedherein, it can be appreciated that the EDGE definition can be bound tomost any industrial automation data type. Moreover, type mappings can beutilized to bind a property within the EDGE definition to the controllerdata. In one example, a strongly-typed property can be provided forcomplex data structures or scalars, a loosely-typed property can beprovided for scalar types (e.g., anyNum) and/or an un-typed property canbe provided for deferred connectivity and/or parameter substitution.

At 904, user interaction with the EDGE definition or the controller datatype can be enabled. Further, at 906, data searching and/or filteringcan be performed based on the user interaction. Moreover, methodology900 provides bi-directional bindings between graphic element definitionsand controller data types, such that, various user scenarios relating todrag/drop, search/filter, and other interactions which improveproductivity can be enabled and an integrated design-time and run-timeexperience can be provided. The example method 900 can be implemented(e.g., executed) by a terminal (e.g., 210) that renders controller data.In an aspect, one or more processors configured to provide or thatprovide the functionality of the one or more terminals can implement thesubject example method.

FIG. 10 illustrates an example methodology 1000 for associating an EDGEwith a data source of an industrial automation environment in accordancewith aspects of the subject disclosure. At 1002, an EDGE definition canbe associated with a data source definition, for example, a UDT or AOI.Further, at 1004, an instance of the EDGE is created, for example in anHMI configuration environment. Moreover, at 1006, the instance isconfigured by populating data source fields based on instances of thedata source type. In one aspect, a user can be prompted with a selectionof suitable data sources from a previously configured program file. Inone example, one or more data value fields, stored and sourced by thedata source, can be associated with properties of the EDGE definition,such that when the EDGE definition is used to create an HMI graphicelement instance, that instance can be populated with information toaccess the data source fields. Typically, associating EDGE definitionswith data source type information can provide easy to builddomain-specific automation design content, connecting logic in a programfile with graphic element content in a configuration file.

Referring to FIG. 11, there illustrated is an example methodology 1100for automatically generating graphic elements according to aspects ofthe subject disclosure. In an embodiment, the terminal (e.g., 210) canperform the subject example methodology 1100. At 1102, HMI faceplatescan be stored within an EOI terminal. Typically, the EOI terminal can becoupled to an industrial automation device, for example, a controller.At 1102, the controller content can be monitored, for example,periodically, at a pre-defined time and/or on-demand. At 1106, HMIscreens can be generated based on an analysis of the content, forexample, automatically, or manually. During automatic generation, anapplication can be created that optimally represents the logic in thecontroller. Further, the logic of the controller can be queried and afaceplate and/or graphic element can be identified based on the logic.Alternately during a manual mode, user input can be received to selectthe controls and/or screen groupings that represent the logic in thecontroller. Furthermore, at 1108, the HMI screens, including graphicelements and/or faceplates, can be updated based on a change in thecontent. For example, addition, modification and/or deletion of acomponent can be detected and the HMI screen can modified accordingly.

Method(s) disclosed throughout the subject specification and annexeddrawings are capable of being stored on an article of manufacture tofacilitate transporting and transferring such method(s) to computers orchipsets with processing capability(ies) for execution, and thusimplementation, by a processor, or for storage in a memory. In anaspect, one or more processors that enact method(s) described herein canbe employed to execute computer-executable code instructions retained ina memory, or any computer-readable or machine-readable medium, toimplement method(s) described herein; the code instructions, whenexecuted by the one or more processor implement or carry out the variousacts in the method(s) described herein. The computer-executable codeinstructions provide a computer-executable or machine-executableframework to enact, or implement, the method(s) described herein.

In order to provide additional context for various aspects thereof, FIG.12 and the following discussion are intended to provide a brief, generaldescription of a suitable computing environment 1200 in which thevarious aspects of the innovation can be implemented. While thedescription above is in the general context of computer-executableinstructions that may run on one or more computers, those skilled in theart will recognize that the innovation also can be implemented incombination with other program modules and/or as a combination ofhardware and software.

Generally, program modules include routines, programs, components, datastructures, etc., that perform particular tasks or implement particularabstract data types. Moreover, those skilled in the art will appreciatethat the inventive methods can be practiced with other computer systemconfigurations, including single-processor or multiprocessor computersystems, minicomputers, mainframe computers, as well as personalcomputers, hand-held computing devices, microprocessor-based orprogrammable consumer electronics, and the like, each of which can beoperatively coupled to one or more associated devices.

The illustrated aspects of the innovation may also be practiced indistributed computing environments where certain tasks are performed byremote processing devices that are linked through a communicationsnetwork. In a distributed computing environment, program modules can belocated in both local and remote memory storage devices.

A computer typically includes a variety of computer-readable media.Computer-readable media can be any available media that can be accessedby the computer and includes both volatile and non-volatile media,removable and non-removable media. By way of example, and notlimitation, computer-readable media can comprise computer storage mediaand communication media. Computer storage media includes both volatileand non-volatile, removable and non-removable media implemented in anymethod or technology for storage of information such ascomputer-readable instructions, data structures, program modules orother data. Computer storage media includes, but is not limited to, RAM,ROM, EEPROM, flash memory or other memory technology, CD-ROM, digitalvideo disk (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by the computer.

Computing devices typically include a variety of media, which caninclude computer-readable storage media and/or communications media,which two terms are used herein differently from one another as follows.Computer-readable storage media can be any available storage media thatcan be accessed by the computer and includes both volatile andnonvolatile media, removable and non-removable media. By way of example,and not limitation, computer-readable storage media can be implementedin connection with any method or technology for storage of informationsuch as computer-readable instructions, program modules, structureddata, or unstructured data. Computer-readable storage media can include,but are not limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disk (DVD) or other optical diskstorage, magnetic cassettes, magnetic tape, magnetic disk storage orother magnetic storage devices, or other tangible and/or non-transitorymedia which can be used to store desired information. Computer-readablestorage media can be accessed by one or more local or remote computingdevices, e.g., via access requests, queries or other data retrievalprotocols, for a variety of operations with respect to the informationstored by the medium.

Communications media typically embody computer-readable instructions,data structures, program modules or other structured or unstructureddata in a data signal such as a modulated data signal, e.g., a carrierwave or other transport mechanism, and includes any information deliveryor transport media. The term “modulated data signal” or signals refersto a signal that has one or more of its characteristics set or changedin such a manner as to encode information in one or more signals. By wayof example, and not limitation, communication media include wired media,such as a wired network or direct-wired connection, and wireless mediasuch as acoustic, RF, infrared and other wireless media.

With reference again to FIG. 12, the example environment 1200 forimplementing various aspects includes a computer 1202, the computer 1202including a processing unit 1204, a system memory 1206 and a system bus1208. The system bus 1208 couples system components including, but notlimited to, the system memory 1206 to the processing unit 1204. Theprocessing unit 1204 can be any of various commercially availableprocessors. Dual microprocessors and other multi-processor architecturesmay also be employed as the processing unit 1204.

The system bus 1208 can be any of several types of bus structure thatmay further interconnect to a memory bus (with or without a memorycontroller), a peripheral bus, and a local bus using any of a variety ofcommercially available bus architectures. The system memory 1206includes read-only memory (ROM) 1210 and random access memory (RAM)1212. A basic input/output system (BIOS) is stored in a non-volatilememory 1210 such as ROM, EPROM, EEPROM, which BIOS contains the basicroutines that help to transfer information between elements within thecomputer 1202, such as during start-up. The RAM 1212 can also include ahigh-speed RAM such as static RAM for caching data.

The computer 1202 further includes an internal hard disk drive (HDD)1214 (e.g., EIDE, SATA), which internal hard disk drive 1214 may also beconfigured for external use in a suitable chassis (not shown), amagnetic floppy disk drive (FDD) 1216, (e.g., to read from or write to aremovable diskette 1218) and an optical disk drive 1220, (e.g., readinga CD-ROM disk 1222 or, to read from or write to other high capacityoptical media such as the DVD). The hard disk drive 1214, magnetic diskdrive 1216 and optical disk drive 1220 can be connected to the systembus 1208 by a hard disk drive interface 1224, a magnetic disk driveinterface 1226 and an optical drive interface 1228, respectively. Theinterface 1224 for external drive implementations includes at least oneor both of Universal Serial Bus (USB) and IEEE 1394 interfacetechnologies. Interface 1224 enables functional coupling of computer1202 to a removable memory, such as a USB memory device or a SD memorycard. Other external drive connection technologies are withincontemplation of the subject innovation.

The drives and their associated computer-readable media providenonvolatile storage of data, data structures, computer-executableinstructions, and so forth. For the computer 1202, the drives and mediaaccommodate the storage of any data in a suitable digital format.Although the description of computer-readable media above refers to aHDD, a removable magnetic diskette, and a removable optical media suchas a CD or DVD, it should be appreciated by those skilled in the artthat other types of media which are readable by a computer, such as zipdrives, magnetic cassettes, flash memory cards, cartridges, and thelike, may also be used in the example operating environment, andfurther, that any such media may contain computer-executableinstructions for performing the methods of the disclosed innovation.

A number of program modules can be stored in the drives and RAM 1212,including an operating system 1230, one or more application programs1232, other program modules 1234 and program data 1236. All or portionsof the operating system, applications, modules, and/or data can also becached in the RAM 1212. It is to be appreciated that the innovation canbe implemented with various commercially available operating systems orcombinations of operating systems.

A user can enter commands and information into the computer 1202 throughone or more wired/wireless input devices, e.g., a keyboard 1238 and apointing device, such as a mouse 1240. Other input devices (not shown)may include a microphone, an IR remote control, a joystick, a game pad,a stylus pen, touch screen, or the like. These and other input devicesare often connected to the processing unit 1204 through an input deviceinterface 1242 that is coupled to the system bus 1208, but can beconnected by other interfaces, such as a parallel port, an IEEE 1394serial port, a game port, a USB port, an IR interface, etc.

A monitor 1244 or other type of display device is also connected to thesystem bus 1208 via an interface, such as a video adapter 1246. Inaddition to the monitor 1244, a computer typically includes otherperipheral output devices (not shown), such as speakers, printers, etc.

The computer 1202 may operate in a networked environment using logicalconnections via wired and/or wireless communications to one or moreremote computers, such as a remote computer(s) 1248. The remotecomputer(s) 1248 can be a workstation, a server computer, a router, apersonal computer, portable computer, microprocessor-based entertainmentappliance, a peer device or other common network node, and typicallyincludes many or all of the elements described relative to the computer1202, although, for purposes of brevity, only a memory/storage device1250 is illustrated. The logical connections depicted includewired/wireless connectivity to a local area network (LAN) 1252 and/orlarger networks, e.g., a wide area network (WAN) 1254. Such LAN and WANnetworking environments are commonplace in offices and companies, andfacilitate enterprise-wide computer networks, such as intranets, all ofwhich may connect to a global communications network, e.g., theInternet.

When used in a LAN networking environment, the computer 1202 isconnected to the local network 1252 through a wired and/or wirelesscommunication network interface or adapter 1256. The adaptor 1256 mayfacilitate wired or wireless communication to the LAN 1252, which mayalso include a wireless access point disposed thereon for communicatingwith the wireless adaptor 1256.

When used in a WAN networking environment, the computer 1202 can includea modem 1258, or is connected to a communications server on the WAN1254, or has other means for establishing communications over the WAN1254, such as by way of the Internet. The modem 1258, which can beinternal or external and a wired or wireless device, is connected to thesystem bus 1208 via the serial port interface 1242. In a networkedenvironment, program modules depicted relative to the computer 1202, orportions thereof, can be stored in the remote memory/storage device1250. It will be appreciated that the network connections shown areillustrative and other means of establishing a communications linkbetween the computers can be used.

The computer 1202 is operable to communicate with any wireless devicesor entities operatively disposed in wireless communication, e.g., aprinter, scanner, desktop and/or portable computer, portable dataassistant, communications satellite, any piece of equipment or locationassociated with a wirelessly detectable tag (e.g., a kiosk, news stand,restroom), and telephone. This includes at least Wi-Fi and Bluetooth™wireless technologies. Thus, the communication can be a predefinedstructure as with a conventional network or simply an ad hoccommunication between at least two devices.

Wi-Fi, or Wireless Fidelity, allows connection to the Internet from acouch at home, a bed in a hotel room, or a conference room at work,without wires. Wi-Fi is a wireless technology similar to that used in acell phone that enables such devices, e.g., computers, to send andreceive data indoors and out; anywhere within the range of a basestation. Wi-Fi networks use radio technologies called IEEE 802.11 (a, b,g, etc.) to provide secure, reliable, fast wireless connectivity. AWi-Fi network can be used to connect computers to each other, to theInternet, and to wired networks (which use IEEE 802.3 or Ethernet).Wi-Fi networks operate in the unlicensed 2.4 and 5 GHz radio bands, atan 11 Mbps (802.11a) or 54 Mbps (802.11b) data rate, for example, orwith products that contain both bands (dual band), so the networks canprovide real-world performance similar to the basic 10BaseT wiredEthernet networks used in many offices.

Referring now to FIG. 13, there is illustrated a schematic block diagramof an example computing environment 1300 in accordance with anotheraspect. The system 1300 includes one or more client(s) 1302. Theclient(s) 1302 can be hardware and/or software (e.g., threads,processes, computing devices). The client(s) 1302 can house cookie(s)and/or associated contextual information by employing the subjectinnovation, for example.

The system 1300 also includes one or more server(s) 1304. The server(s)1304 can also be hardware and/or software (e.g., threads, processes,computing devices). The servers 1304 can house threads to performtransformations by employing the invention, for example. One possiblecommunication between a client 1302 and a server 1304 can be in the formof a data packet adapted to be transmitted between two or more computerprocesses. The data packet may include a cookie and/or associatedcontextual information, for example. The system 1300 includes acommunication framework 1306 (e.g., a global communication network suchas the Internet) that can be employed to facilitate communicationsbetween the client(s) 1302 and the server(s) 1304.

Communications can be facilitated via a wired (including optical fiber)and/or wireless technology. The client(s) 1302 are operatively connectedto one or more client data store(s) 1308 that can be employed to storeinformation local to the client(s) 1302 (e.g., cookie(s) or associatedcontextual information). Similarly, the server(s) 1304 are operativelyconnected to one or more server data store(s) 1310 that can be employedto store information local to the servers 1304.

In the subject specification and annexed drawings, terms such as“repository,” “store,” “data store,” “data storage,” and substantiallyany term(s) that convey other information storage component(s) relevantto operation and functionality of a functional element or componentdescribed herein, refer to “memory components,” or entities embodied ina “memory” or components comprising the memory. The memory componentsdescribed herein can be either volatile memory or nonvolatile memory, orcan include both volatile and nonvolatile memory. In addition, thememory components described herein can be statically affixed (screwed,bolted, soldered, etc.) or removably affixed. Further, the memorycomponents can include computer-readable or machine-readable storagemedia.

By way of illustration, and not limitation, nonvolatile memory caninclude read only memory (ROM), programmable ROM (PROM), electricallyprogrammable ROM (EPROM), electrically erasable ROM (EEPROM), or flashmemory. Volatile memory can include random access memory (RAM), whichacts as external cache memory. By way of further illustration and notlimitation, RAM can be available in many forms such as synchronous RAM(SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rateSDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), anddirect Rambus RAM (DRRAM). Additionally, the disclosed memory componentsof systems or methods herein are intended to comprise, without beinglimited to comprising, these and any other suitable types of memory.

The various illustrative logics, logical blocks, modules, and circuitsdescribed in connection with the embodiments disclosed herein may beimplemented or performed with a general purpose processor, a digitalsignal processor (DSP), an application specific integrated circuit(ASIC), a field programmable gate array (FPGA) or other programmablelogic device (e.g., a PAC), discrete gate or transistor logic, discretehardware components, or any combination thereof designed to perform thefunctions described herein. A general-purpose processor may be amicroprocessor, but, in the alternative, the processor may be anyconventional processor, controller, microcontroller, or state machine. Aprocessor may also be implemented as a combination of computing devices,e.g., a combination of a DSP and a microprocessor, a plurality ofmicroprocessors, one or more microprocessors in conjunction with a DSPcore, or any other such configuration. Additionally, at least oneprocessor may comprise one or more modules operable to perform one ormore of the steps and/or actions described above.

Further, the steps or acts of a method or algorithm described inconnection with the aspects disclosed herein may be embodied directly inhardware, in a software module executed by a processor, or in acombination of the two. A software module may reside in RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a harddisk, a removable disk, a CD-ROM, or any other form of storage mediumknown in the art. An example storage medium may be coupled to theprocessor, such that the processor can read information from, and writeinformation to, the storage medium. In the alternative, the storagemedium may be integral to the processor. Further, in some aspects, theprocessor and the storage medium may reside in an ASIC. Additionally,the ASIC may reside in a user terminal. In the alternative, theprocessor and the storage medium may reside as discrete components in auser terminal. Additionally, in some aspects, the steps and/or actionsof a method or algorithm may reside as one or any combination or set ofcodes and/or instructions on a machine readable medium and/or computerreadable medium, which may be incorporated into a computer programproduct.

In one or more aspects, the functions described may be implemented inhardware, software, firmware, or any combination thereof. If implementedin software, the functions may be stored or transmitted as one or moreinstructions or code on a computer-readable medium. Computer-readablemedia includes both computer storage media and communication mediaincluding any medium that facilitates transfer of a computer programfrom one place to another. A storage medium may be any available mediathat can be accessed by a computer. By way of example, and notlimitation, such computer-readable media can comprise RAM, ROM, EEPROM,CD-ROM or other optical disk storage, magnetic disk storage or othermagnetic storage devices, or any other medium that can be used to carryor store desired program code in the form of instructions or datastructures and that can be accessed by a computer. Also, any connectionmay be termed a computer-readable medium. For example, if software istransmitted from a website, server, or other remote source using acoaxial cable, fiber optic cable, twisted pair, digital subscriber line(DSL), or wireless technologies such as infrared, radio, and microwave,then the coaxial cable, fiber optic cable, twisted pair, DSL, orwireless technologies such as infrared, radio, and microwave areincluded in the definition of medium. Disk and disc, as used herein,includes compact disc (CD), laser disc, optical disc, digital versatiledisc (DVD), floppy disk and blu-ray disc where disks usually reproducedata magnetically, while discs usually reproduce data optically withlasers. Combinations of the above should also be included within thescope of computer-readable media.

What has been described above includes examples of the disclosedinnovation. It is, of course, not possible to describe every conceivablecombination of components and/or methodologies, but one of ordinaryskill in the art may recognize that many further combinations andpermutations are possible. Accordingly, the innovation is intended toembrace all such alterations, modifications and variations that fallwithin the spirit and scope of the appended claims. Furthermore, to theextent that the term “includes” is used in either the detaileddescription or the claims, such term is intended to be inclusive in amanner similar to the term “comprising” as “comprising” is interpretedwhen employed as a transitional word in a claim.

What is claimed is:
 1. A method, comprising: in response to determiningthat a first data type associated with a property of a definition of agraphic element has been mapped with a second data type and in responseto a selection of the definition of the graphic element, facilitating,by a system comprising a processor, a display of a set of controllertags that support the second data type; determining, based on metadataassociated with the definition, that the property has be assigned as anoptional property; and in response to receiving input data that bindsthe definition of the graphic element to a controller tag of the set ofcontroller tags, facilitating a presentation of an instance of thegraphic element based on data from the controller tag.
 2. The method ofclaim 1, wherein the set of controller tags is a first set of firstcontroller tags and the facilitating the display comprises facilitatingthe display of a second set of second controller tags that support thefirst data type.
 3. The method of claim 2, wherein the input data is afirst input data, the controller tag is a first controller tag, thepresentation is a first presentation, the instance is a first instance,the data is first data, and the method further comprises: in response toreceiving second input data that binds the definition of the graphicelement to a second controller tag of the second set of secondcontroller tags, facilitating a second presentation of a second instanceof the graphic element based on second data from the second controllertag.
 4. The method of claim 1, wherein the selection is a firstselection, the display is a first display, and the method furthercomprises: in response to a second selection of the controller tag,facilitating a second display of a set of definitions of graphicelements comprising the definition of the graphic element, wherein a setof respective properties of the definitions of the graphic elements isassociated with the second data type.
 5. The method of claim 1, furthercomprising: based on the input data, configuring a set of respectivebindings for a set of internal items of the graphic element.
 6. Themethod of claim 1, further comprising: in response to the determiningthat the property has been assigned as the optional property, receivingconfiguration data that configures a binding of the property, whereinthe facilitating the presentation comprises facilitating thepresentation based on the configuration data.
 7. The method of claim 1,further comprising: mapping the first data type with the second datatype in response to determining that the property is a strongly-typedproperty, wherein the strongly-typed property specifies that the firstdata type is to match a third data type of a bound tag.
 8. The method ofclaim 1, wherein the property is a first property and the method furthercomprises: in response to determining a second property of thedefinition of the graphic element is a loosely-typed property,verifying, subsequent to the facilitating the presentation, a validityof a third data type of a bound tag.
 9. A human machine interface,comprising: a memory that stores computer executable instructions; and aprocessor, communicatively coupled to the memory, that executes theinstructions to perform acts, comprising: determining mapping data thatspecifies mapping of a first data type associated with a property of adefinition of a graphic element with a second data type, wherein theproperty has been determined to be assigned as an optional propertybased on metadata associated with the definition; in response toreceiving selection data that selects the definition of the graphicelement, causing to be generated a display of a set of controller tagsthat support the second data type; and in response to receiving inputdata that binds the definition of the graphic element to a controllertag of the set of controller tags, configuring an instance of thegraphic element based at least in part on data from the controller tag.10. The human machine interface of claim 9, wherein the graphic elementincludes at least one of an externally generated graphic elementreceived from an original equipment manufacturer or a user definedgraphic element.
 11. The human machine interface of claim 9, wherein theset of controller tags is a first set of first controller tags and thecausing to be generated comprises causing to be generated the display ofa second set of second controller tags that support the first data type.12. The human machine interface of claim 9, wherein the operationsfurther comprise: subsequent to the determining, updating avisualization of the definition of the graphic element to specify thatthe definition of the graphic element supports the second data type. 13.The human machine interface of claim 9, wherein the selection data isfirst selection data, the display is a first display, and the operationsfurther comprise: in response to a second selection of the controllertag, causing to be generated a second display of a set of definitions ofgraphic elements comprising the definition of the graphic element,wherein a set of respective properties of the definitions of the graphicelements support the second data type.
 14. The human machine interfaceof claim 9, wherein the operations further comprise: in response to thedetermining that the property has been assigned as the optionalproperty, initiating a design-time validation to facilitate adetermination of a binding problem.
 15. The human machine interface ofclaim 9, wherein the property is a strongly-typed property and the firstdata type is a structured data type.
 16. The human machine interface ofclaim 9, wherein the definition of the graphic element comprises aloosely-typed property that is associated with a scalar data type. 17.The human machine interface of claim 16, wherein the controller tag is afirst controller tag and the operations further comprise: subsequent toa presentation of the instance, verifying that a conversion from a thirddata type of a second controller tag of the controller tags that isbound to the loosely-typed property, to the scalar data type, is valid.18. A non-transitory computer readable storage medium comprisingcomputer-executable instructions that, in response to execution, causean industrial automation device comprising a processor to performoperations, comprising: facilitating a mapping of a first data typeassociated with a property of a definition of a graphic element with aset of second data types, wherein the property has been determined to beassigned as an optional property based on metadata associated with thedefinition; in response to receiving first selection data that selectsthe definition of the graphic element, facilitating a first display of aset of controller tags that support the set of second data types; and inresponse to receiving second selection data that selects a controllertag of the set of controller tags, facilitating a second display of aset of definitions of graphic elements having respective properties thatsupport the set of second data types, wherein the set of definitions ofgraphic elements comprises the definition of the graphic element. 19.The non-transitory computer readable storage medium of claim 18, whereinthe operations further comprise: in response to receiving input datathat binds the definition of the graphic element to the controller tag,configuring an instance of the graphic element based on data from thecontroller tag.
 20. The non-transitory computer readable storage mediumof claim 18, wherein the operations further comprise: in response to thedetermining that the property has been determined to be assigned as theoptional property, initiating a design-time validation to facilitate adetermination of a binding problem.